apps/generator/docs/generator-template-java.md (1)

318-318: Wording drift: this should reference operations, not channels.

Since this section migrates to AsyncAPI v3 operations, “regardless of the number of channels” is misleading here.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/generator/docs/generator-template-java.md` at line 318, The sentence
currently references "channels" but this section is about AsyncAPI v3
operations; update the wording around the `TopicFunction` description to
reference "operations" (or "the number of operations in the AsyncAPI v3
document") instead of "channels" so it accurately reflects that the reusable
component applies regardless of operation count in the asyncAPI v3 document.

apps/generator/docs/generator-template-java.md (1)

356-357: ⚠️ Potential issue | 🔴 Critical

Operation direction is inconsistent, so generated send... methods will be missing.

At Line 356, the tutorial filters with operations.filterBySend(), but at Line 473 and Line 477 both operations are action: receive. This produces no topic methods, while Line 503 and Line 506 call sendTemperatureDrop/Rise, so the tutorial flow breaks.

Suggested fix

 operations:
   temperatureDrop:
-    action: receive
+    action: send
     channel:
       $ref: '#/channels/temperature~1dropped'
   temperatureRise:
-    action: receive
+    action: send
     channel:
       $ref: '#/channels/temperature~1risen'

#!/bin/bash
# Verify direction mismatch between filter and AsyncAPI operation actions in this tutorial file.
set -euo pipefail

FILE="apps/generator/docs/generator-template-java.md"

echo "== filter usage =="
rg -n "filterBySend|filterByReceive" "$FILE"

echo
echo "== operation actions in YAML snippet =="
rg -n "operations:|temperatureDrop:|temperatureRise:|action:" "$FILE" -A3 -B1

echo
echo "Expected: if filterBySend is used for method generation, operations should use action: send."

Based on learnings: “AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x: operations become top-level elements with action property (send/receive) and references to channels.”

Also applies to: 472-479, 503-507

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/generator/docs/generator-template-java.md` around lines 356 - 357, The
tutorial uses operations.filterBySend() but assigns it to receiveOperations, and
the AsyncAPI examples define operations with action: receive, so generated
send... methods are missing; update the usage to match intent by either changing
the filter to operations.filterByReceive() (if you want receive operations) or
updating the sample YAML operations' action values to send (if you intend to
generate send methods), and ensure the variable name receiveOperations and any
subsequent calls to sendTemperatureDrop/Rise or send... methods are consistent
with the chosen filter and operation action.

apps/generator/docs/generator-template-java.md (1)

349-350: Comments/identifier naming drift from behavior; please align wording.

receiveOperations (Line 356) actually stores filterBySend() results, and comments at Line 349-350 / Line 380 still talk about receive operations. This is confusing in a tutorial and easy to copy incorrectly.

Suggested cleanup

- * This function returns a list of objects, one for each receive operation.
+ * This function returns a list of objects, one for each send operation.
...
- const receiveOperations = operations.filterBySend();
+ const sendOperations = operations.filterBySend();
...
- receiveOperations.forEach((op) => {
+ sendOperations.forEach((op) => {

Based on learnings: “Update relevant Generator documentation to accurately reflect PR changes introduced.”

Also applies to: 356-360, 380-380

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/generator/docs/generator-template-java.md` around lines 349 - 350, The
comments in the generator-template-java.md are misleading: the variable
receiveOperations actually stores results from filterBySend(), i.e., send
operations; update all relevant comment text that mentions "receive operations"
(references: receiveOperations, filterBySend()) to correctly say "send
operations" or "filtered send operations" and adjust the descriptive lines (the
block describing name/operationId and any nearby bullets) so they reflect that
the list contains send-operation objects rather than receive-operation objects.